* New upstream release (5.52.0).
* Update build-deps and deps with the info from cmake
* New upstream release (5.53.0).
* Update build-deps and deps with the info from cmake
* New upstream release (5.54.0).
* Update build-deps and deps with the info from cmake
* Bump group breaks (5.54)
* Release to unstable
Francis Herne [Sun, 19 Feb 2017 20:01:38 +0000 (20:01 +0000)]
KColorScheme: default to application scheme if set by KColorSchemeManager
KColorSchemeManager::activateScheme() sets a custom path for the
application's color scheme, with
`qApp->setProperty("KDE_COLOR_SCHEME_PATH", index.data(Qt::UserRole));`
Currently, the KColorScheme() and KStatefulBrush() constructors will
ignore this and use only the system color scheme, unless an
application-specific config is explicitly loaded and passed in by the
caller.
This is problematic, because most callers assume that the default is to
match the *application* scheme - usually this is equivalent, but it
differs when KColorSchemeManager is used.
For example, when the application of a KTextEditor widget or
KonsolePart has an opposite color scheme to the system, the Find bars
are unreadable.
BUG: 373764
This patch makes KColorScheme() match the application scheme by default
when this differs from the system scheme, which seems preferable to
adding the same code in hundreds of callers.